home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 6463 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.8 KB
  1. Path: admaix.sunydutchess.edu!ub!newserve!rebecca!rpi!not-for-mail
  2. From: James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de>
  3. Newsgroups: comp.lang.c++,comp.lang.c++.moderated
  4. Subject: Re: Q: stack corrupted before main()?
  5. Date: 8 Feb 1996 16:35:01 -0000
  6. Organization: unknown
  7. Sender: cppmods@netlab.cs.rpi.edu
  8. Approved: vandevod@cs.rpi.edu
  9. Message-ID: <4fd8nl$9nb@netlab.cs.rpi.edu>
  10. References: <4f8423$kp9@netlab.cs.rpi.edu>
  11. NNTP-Posting-Host: netlab.cs.rpi.edu
  12. X-Original-Date: Thu, 8 Feb 96 16:23:40 +0100
  13.  
  14. In article <4f8423$kp9@netlab.cs.rpi.edu> Jacek Surazski
  15. <jaceks@stud.unit.no> writes:
  16.  
  17. |> The project I am currently working on is exhibiting the following behavior:
  18. |> the stack is corrupted even before control enters main(). That is, when I 
  19. |> run it under a debugger and view the stack, it shows names of non-existent
  20. |> functions
  21. |> even as the control pointer is still on the main() header. If I try to step
  22. |> through the program, the stack shows new non-existant, and occasionally
  23. |> existant but incorrect functions, whenever I step into a function in the
  24. |> code.
  25.  
  26. The most likely explination is that the debugger is looking at the
  27. wrong binary for the symbols.  Of course, `non-existant' functions are
  28. to be expected, since (presumably) the debugger also shows the system
  29. functions which invoke main.  (Under Unix, this would correspond to
  30. crt0, but I don't know what the conventions are for MS-DOS.)  Since
  31. you say later that you are compiling under DOS, is it possible that
  32. you have somehow mixed your compilation modes.  I can imagine that a
  33. debugger would have considerable problems if it thinks that the
  34. program was compiled in large, when in fact it was compiled in small.
  35. (Again, I'm not familiar with modern DOS software, but is it possible
  36. that your main module was compiled in small, then linked with the
  37. large model start-up routines, or vice-versa?)
  38.  
  39. |> The project is written for dos, and I am using bc 3.1. I've tried to "boil
  40. |> down" the problem to as small a piece of code as possible, but it proved 
  41. |> a bit bewildering, as no single chunk appeared to be responsible. Removing
  42. |> miscelenous bits from here and there seemed to allivate the problem, but 
  43. |> these bits apparently had nothing in common. I have come to the conclusion,
  44. |> that perhaps this is a configuration problem?
  45.  
  46. The symptoms you describe are typical of pointer problems.  Removing a
  47. bit of code having nothing to do with the problem will change the
  48. addresses of the rest of the program (and data) in memory; the write
  49. through an uninitialized pointer will then modify different data (thus
  50. changing the symptoms)..
  51.  
  52.       [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
  53.       [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
  54.       [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
  55.       [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]
  56.